feature: instance boot group and readiness rules - #13907

ui/src/core/lazy_lib/icons_use.js:365

• VerticalAlignMiddleOutlined is registered twice on the Vue app, which is redundant and can mask issues when refactoring the icon list. Remove the duplicate component registration.

ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1

• a-form's @finish handler is invoked with form values (not a DOM event). As written, handleSubmit will throw when called from @finish because e.preventDefault() is executed on a non-event/undefined. Make handleSubmit tolerant of non-event invocations (e.g., only call preventDefault when present) or split into separate submit handlers for click vs. finish.
  ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1
• a-form's @finish handler is invoked with form values (not a DOM event). As written, handleSubmit will throw when called from @finish because e.preventDefault() is executed on a non-event/undefined. Make handleSubmit tolerant of non-event invocations (e.g., only call preventDefault when present) or split into separate submit handlers for click vs. finish.
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• Same issue as the update-order modal: @finish passes form values, not a DOM event, so e.preventDefault() can throw and break submission. Update handleSubmit to safely handle calls from both @finish and button/keyboard events.
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• Same issue as the update-order modal: @finish passes form values, not a DOM event, so e.preventDefault() can throw and break submission. Update handleSubmit to safely handle calls from both @finish and button/keyboard events.
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• The form currently only validates order, so it’s possible to submit without selecting a VM/InstanceGroup, relying on backend errors. Add client-side required validation for virtualmachineid when membertype is VirtualMachine, and for instancegroupid when membertype is InstanceGroup (and consider clearing validation errors when toggling member type).
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• The form currently only validates order, so it’s possible to submit without selecting a VM/InstanceGroup, relying on backend errors. Add client-side required validation for virtualmachineid when membertype is VirtualMachine, and for instancegroupid when membertype is InstanceGroup (and consider clearing validation errors when toggling member type).
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• The form currently only validates order, so it’s possible to submit without selecting a VM/InstanceGroup, relying on backend errors. Add client-side required validation for virtualmachineid when membertype is VirtualMachine, and for instancegroupid when membertype is InstanceGroup (and consider clearing validation errors when toggling member type).
  core/src/main/java/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java:1
• This handler hard-codes _eachTimeout to 60 seconds and ignores the wait set on the command (cmd.setWait(...) is used by the callers to respect an attempt budget). This can cause attempts to exceed the intended budget or time out too early. Use the command’s wait value (or derive _eachTimeout from it) instead of a fixed constant.
  server/src/main/java/org/apache/cloudstack/vm/bootgroup/readiness/VrPingChecker.java:1
• The code casts Answer to InstanceReadinessCheckAnswer without verifying the type or checking answer.getResult(). In mixed-version/upgrade scenarios or when the VR can’t execute the script, the agent may return a different Answer type or a failure response, leading to ClassCastException and breaking readiness evaluation. Guard with instanceof, handle !answer.getResult() explicitly, and surface answer.getDetails() as the error message.
  server/src/main/java/org/apache/cloudstack/vm/bootgroup/readiness/PortCheckChecker.java:1
• Same unsafe cast pattern as VrPingChecker: Answer is cast to InstanceReadinessCheckAnswer without instanceof/getResult() checks. This can crash the checker and abort readiness computation. Add defensive checks and handle failed answers by returning Status.Error with the agent-provided details.
  engine/schema/src/main/java/com/cloud/vm/dao/InstanceBootGroupReadinessCheckResultDaoImpl.java:1
• This upsert is not atomic: concurrent writers can both observe existing == null and then attempt persist, violating the unique key on (rule_id, vm_id) and causing intermittent failures under parallel readiness evaluation. Wrap this in a transaction with appropriate locking, or implement a DB-level upsert pattern (e.g., try-insert then update on duplicate) so concurrent updates are safe.
  core/src/main/java/org/apache/cloudstack/vm/bootgroup/readiness/InstanceReadinessCheckAnswer.java:1
• The answer parsing relies on a string delimiter (&&) and throws a runtime exception if the format isn't exactly as expected. Any unexpected script output (including delimiter collisions) will bubble up as an exception and can disrupt readiness evaluation. Consider switching the VR script to emit structured output (e.g., JSON with stdout/stderr/exitcode fields) and make the parser fail-soft (returning exitcode=-1 with a descriptive stderr) rather than throwing.

Previously missed (3) — in code that hasn't changed since the last review.

core/src/main/java/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java:500

• InstanceReadinessCheckCommand.setWait(...) is computed from the remaining budget, but this handler hardcodes _eachTimeout to 60s. This makes the command’s per-attempt wait budget ineffective (the VR script execution timeout can exceed the intended budget).
  plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtCheckGuestAgentLivenessCommandWrapper.java:74
• The wrapper uses a fixed 5s timeout for qemuAgentCommand(...) and ignores command.getWait(), even though the caller sets the command wait from the remaining readiness budget. This can cause false negatives when the readiness attempt budget is higher than 5s.
  server/src/main/java/org/apache/cloudstack/vm/bootgroup/InstanceBootGroupMembershipGuard.java:99
• validateVmEligibleForGroupMembership only checks the first Instance Group mapping for the VM (currentMappings.get(0)). Since instance_group_vm_map does not enforce one-group-per-VM, a VM can be in multiple instance groups, and this can miss a disqualifying group that is already a boot-group member.

ui/src/views/compute/AddInstanceBootGroupMember.vue:120

• The form validation only enforces order, so it’s possible to submit without selecting a VM/instance group, which will send an API request missing the required virtualmachineid/instancegroupid parameter.